%  Copyright (C) 2002 Regents of the University of Michigan, portions used with permission 
%  For more information, see http://csem.engin.umich.edu/tools/swmf
%\documentclass{article} \begin{document}
\chapter{Output files \label{chapter:output}}

\section{Restart files \label{section:restart_output}}

Restart files contain all the necessary information that enables \BATSRUS\ 
to continue a simulation from a given point. The parameters following
the \#SAVERESTART command in PARAM.in determine when the restart files 
are written to the disk. The restart files are written into the 
output restart directory, which has the default name
\begin{verbatim}
  restartOUT/
\end{verbatim}
The default name can be changed with the \#RESTARTOUTDIR command in PARAM.in.
The state variables are stored in the binary files
\begin{verbatim}
  restartOUT/blkGLOBALBLKNUMBER.rst
\end{verbatim}
Note that the files are written out block by block, so that
at restart the blocks can be distributed among the processors differently
than they were at the time of the save. This means that a simulation
can be continued with a different number of processors after restart.
On the other hand the file names do not contain the time step, so they
get overwritten every time new restart files are produced. This avoids
the problem of filling up the disk with restart files. The only way to
keep restart files is to rename the restartOUT directory. For example
\begin{verbatim}
  mv restartOUT restart_n120000
  mkdir restartOUT
\end{verbatim}
Remember to create an empty restartOUT directory, otherwise the code will
crash when it attempts to write a restart. Moving the restartOUT file
can be done even while the code is running, except when the restart
files are being written. Alternatively you can create several directories
in advance and change the name of the output restart directory with
the \#RESTARTOUTDIR command from session to session.

If you want \BATSRUS\ to read the restart files in,
they have to be located in the input restart directory.
The default name is
\begin{verbatim}
  restartIN/
\end{verbatim}
Rather than moving the files into this directory, we suggest
the use of a symbolic link. For example
\begin{verbatim}
  ln -s restart_n120000 restartIN
\end{verbatim}
will make the code read the files from the {\tt restart\_n120000} directory
if a restart is initiated in PARAM.in.
Alternatively, you can use the \#RESTARTINDIR command in the PARAM.in file
to change the name of the input restart directory.

In addition to the block data files, the restart directory contains two
more files. The octree grid structure is described by the binary file
\begin{verbatim}
  restartOUT/octree.rst
\end{verbatim}
while the ASCII header file
\begin{verbatim}
  restartOUT/restart.H
\end{verbatim}
contains time step and time information for the restart. It also signals
whether the restart files contain extra data for face centered 
magnetic field variables for the constrained transport scheme.

\subsection{Conversion of binary restart files with ConvertRestart.pl}

The binary restart files, like all binary Fortran files, 
are platform dependent. Platforms differ in how they order the
bytes in the 4 or 8 byte data units, such as integers, real numbers,
logicals and record length markers. For example the Linux PC, the
SGI Altix and the Compaq OSF1 machines are 'little endian', 
while the SGI Origin is 'big endian'. 

We have developped a tool that makes the conversion of the restart files 
rather easy. The {\tt Scripts/ConvertRestart.pl} perl script can convert a 
complete restart directory, for example
\begin{verbatim}
  mkdir run/restart_converted
  Scripts/ConvertRestart.pl run/restart_original run/restart_converted
\end{verbatim}
Depending on the number and size of the restart files conversion may take 
from a few minutes to an hour.

\section{Logfiles \label{section:logfiles}}

The logfiles are very useful to check conservation of quantities,
to see when not-a-numbers (NaN) first appeared before the code crashed,
or it can contain physically relevant pointwise values. Writing
the logfile is fairly fast, and the logfile is relatively small,
so it can be easily done every time step if that is necessary 
(e.g. for debugging).

The ASCII logfile is written into the plot directory. The default name is
\begin{verbatim}
  IO2/
\end{verbatim}
The name of the directory is historical (there used to be an IO directory),
and it can be changed with the \#PLOTDIR command in the PARAM.in file.
The frequency of saves and the content of the logfile are controlled by
the \#SAVELOGFILE command in PARAM.in. The logfile is named 
\begin{verbatim}
  IO2/log_timestep.log
\end{verbatim}
where {\tt timestep} refers to the time step when the logfile
is opened. The logfile is only closed at the end of the run.
The logfile has a very simple structure:
\begin{verbatim}
headerline
it t var1 var2 var3 ...
...
\end{verbatim}
where the {\tt headerline} is a string describing the content.
The second line is a list of the function names that are saved usually
starting with time step number and time 
(see the \#SAVELOGFILE command for details). 
All subsequent lines contain the values for these functions
at the given time step. The logfile can be viewed with the 
UNIX {\tt more} command or with any editor ({\bf but do not use an
editor if \BATSRUS\ is running and the logfile is still open}), 
or it can be read with the {\tt .r getlog} script into IDL and plotted.

\section{Satellite Files \label{section:satellitefiles}}

Satellite files  are used to extract information along a satellite
trajectory.  This is most useful in time accurate runs when 
saving the full 3D files frequently enough to extract the data along
the trajectory in post processing is prohibitive.  However, they
have other uses.

The ASCII satellite files are also written into the plot directory.
The frequency of saves and the content of the satellite files 
are controlled by the {\tt \#SATELLITES} command in PARAM.in. 
The satellite files are
\begin{verbatim}
  IO2/satelite_NN_satelitename.sat
\end{verbatim}
where {\tt NN} refers to the number of the satellite and 
{\tt satellitename} is obtained from the input from PARAM.in.
These files are closed at the end of the run.
The satellite files have the same structure as the log file:
\begin{verbatim}
headerline
it t var1 var2 var3 ...
...
\end{verbatim}
where the {\tt headerline} is a string describing the content.
The second line is a list of the function names that are saved
starting with time step number and time 
(see the \#SATELLITE command for details).
All subsequent lines contain the values for these functions
at the given time step. The satllite files can be viewed with the 
UNIX {\tt more} command or with any editor ({\bf but do not use an
editor if \BATSRUS\ is running and the files are  still open}). 

\section{Plotfiles \label{section:plotfiles}}

Plot files are used for visualization of spatially and temporarily 
distributed data. They can contain the values of various functions 
along 1, 2 or 3 dimensional cuts of the computational domain. 
A series of plot files can be used to animate the time evolution.

All the plotfiles are written into the plot directory, which has
the default name {\tt IO2/} which can be changed with the \#PLOTDIR command.
The type and number of plot files and the frequency of saves  
are controlled by the \#SAVEPLOT command in PARAM.in.

Separate plot files are written out by each processor. The file names
ensure that different plot files have different names, and previously
written saves do not get overwritten. The name looks like this
\begin{verbatim}
  IO2/plotarea_plotvar_plotnumber_timestep_PEnumber.plotform
\end{verbatim}
where {\tt plotarea} and {\tt plotvar} are given in PARAM.in,
{\tt plotnumber} is the serial number of the plot file based
on the order of plot file definitions after the \#SAVEPLOT command;
{\tt timestep} is the number of time steps for the whole simulation;
{\tt PEnumber} is the processor (starting from 0); and finally
{\tt plotform} is 'idl' for IDL and 'tec' for TEC files.

The IDL files contain cell centered data, such as cell size, cell center
position, and function values, while the TEC files contain
data interpolated to cell corners. The TEC files are always in ASCII
format.
The IDL files can be ASCII or binary as determined by the \#SAVEBINARY
command in PARAM.in. Binary files are smaller, faster to write, 
and there is no loss of accuracy, so this is the default. The ASCII files
on the other hand, are human readable, and transferable between machines.

In addition to the '*.idl' and '*.tec' files, an ASCII header file is written
for each plotfile with a name
\begin{verbatim}
  IO2/plotarea_plotvar_plotnumber_timestep.headextension
\end{verbatim}
where headextension is 'h' for the IDL and 'T' for the Tecplot file formats.
The header files contain basic information, like time step, time,
variable names, variable units etc. An exception to the above header 
extension is for the spherical cut plot files (plotarea='sph').  
The Tecplot header files for these plots have the headextension 'S'.

\section{Postprocessing the IDL plot files \label{section:postidl}}

Since the plot files are produced by each processor separately, it is
necessary to collect the data and produce a single plot file. 
Furthermore, we can produce a single structured grid with a fixed 
resolution defined by the DxSavePlot parameter in the \#SAVEPLOT command.
The requested resolution is saved in the .h header file. 
The differently sized cells must be restricted and prolonged
(with first order accuracy) into equally sized cells, which then must be
arranged into a structured grid. When the files contain a 2D cut (e.g. y=0), 
the data in the cells on the two sides of the cut plane must be averaged.
This is done both for structured and unstructured grids.

All the data collection and transformation described above are done by the
\begin{verbatim}
  PostIDL.exe
\end{verbatim}
code. To make this executable simply type 
\begin{verbatim}
  make PIDL
\end{verbatim}
in the main directory. In the run directory there is a symbolic link
to PostIDL.exe. To post process all the .idl files for a single
plot, type for example
\begin{verbatim}
  PostIDL.exe < IO2/y=0_MHD_1_n0001200.h
\end{verbatim}
in the run directory. The PostIDL code will read the headerfile, and
all the corresponding .idl files, and it will produce a single binary file
\begin{verbatim}
  IO2/y=0_MHD_1_n0001200.out
\end{verbatim}
This file contains all the header information and the information collected
from the .idl files. It can be read and visualized with the IDL macros
provided in the Idl/ directory. Therefore the .h and .idl files can be
deleted.

When there are many plotfiles produced by a simulation, all the Postprocessing
can be done with a single command by running the
\begin{verbatim}
  pIDL
\end{verbatim}
script. There is a link in the run directory to this script. The {\tt pIDL} 
script does the post processing for all plots with a corresponding
.h header file in the IO2/ directory. After post processing it deletes the
.h and .idl files automatically. This default behavior can be modified
with the two optional arguments. The first argument limits the post processing
to a subset of the plots, e.g.
\begin{verbatim}
  pIDL IO2/x=0
\end{verbatim}
will only process the plotfiles whose names start with 'x=0'. The second
argument tells pIDL that the .h and .idl files should be kept. For example
\begin{verbatim}
  pIDL IO2/ KEEP
\end{verbatim}
will process all the plots, but it keeps the original data files too.

The PostIDL.exe program can read both ASCII and binary .idl files. 
For binary .idl files, however, it is important to have the same
precision for reals as in \BATSRUS, ie. PostIDL.exe and BATSRUS.exe
should be compiled with the same PRECISION definition in the Makefile.
The output of PostIDL.exe is a binary file, because IDL reads
binary files much faster than ASCII files. It also saves disk space.
For testing purposes, however, {\tt /src/PostIDL.exe} can be edited to contain
\begin{verbatim}
  logical, parameter :: write_binary=.false.
\end{verbatim}
instead of the default .true. value. After recompilation with {\tt make PIDL},
the modified PostIDL.exe code will write ASCII output files. 

\subsection{Conversion of binary .out files with FixEndian.pl 
            \label{section:convert_bin}}

The {\bf Scripts/IDL/FixEndian.pl} Perl script solves the problems of 
transporting the binary .out files between different platforms.
The script can tell whether a machine is big endian or little
endian (these differ in the ordering of bytes for integers and reals),
and it can test and convert the endianness of binary .out files,
both in double and single precisions. As an additional benefit,
the 8-byte integers used by Cray can be converted to 4 byte integers
and vice-versa.

Note that the 'assign -F f77 u=12' command has to be used on the Cray 
before running PostIDL.exe, so that the output file is in Fortran 77 
binary format. Then the file should be FTP-d to a workstation/PC, and the 
FixEndian.pl script should be executed there. The script does not work on
the Cray, because even the Perl interpreter is non-standard on a Cray.

Type {\bf Scripts/IDL/FixEndian.pl} without any parameters to see the 
syntax of usage.
An example of usage is to check the content of a data file with the
{\bf -t} flag (test):
\begin{verbatim}
Scripts/IDL/FixEndian.pl -t run/IO2/y=0_mhd_1_n0001200.out

This is a big endian machine.

run/IO2/y=0_mhd_1_n0001200.out is a big endian single precision file.

headline=normalized variables
it=1200 t=0 ndim=2 neqpar=2 nw=11
nx=256,128
eqpar=1.66666,0
names=x z rho ux uy uz bx by bz p jx jy jz g cuty
...
\end{verbatim}
The above output was obtained on an SGI workstation for a .out file 
obtained with an SGI Origin. In this case no conversion is required.

\section{Postprocessing the TEC plot files \label{section:posttec}}

Since the plot files are produced by each processor separately, it is
necessary to collect the data and produce a single plot file. 
Furthermore, Tecplot output files contain cell corner data rather
than the cell centered data of IDL.  Node numbering and block edge
synchronization occur prior to output so that very little processing
needs to be done with the output files.

Processing the {\tt .tec} files happens in two separate steps.  First,
the individual files from each processor for each plot have to be 
concatenated together and renamed as {\tt .dat} files.  Next, the
files can be be processed with {\tt preplot}, an application
included with Tecplot, which creates a binary file in tecplot native format.

A script has been created to more easily process Tecplot data.  There
is a link to this script called 
\begin{verbatim}
  pTEC
\end{verbatim}
in the run directory.  This script handles the processing of several
different output data products including standard 2 or 3 dimensional
output slices and spherical slice files in the {\tt IO2/} directory.
Typing
\begin{verbatim}
  pTEC -help
\end{verbatim}
gives the following documentation on the type of arguments to {\tt pTEC} 
and their functionality.
\begin{verbatim}
Usage:

pTEC [p,r,g,I,S,T,A,b=BASENAME]

The order of flags does not matter.  A maximum of 6 flags can be used.       

- No arguments default to 'T'. See below.                                    
- If 'S' then spherical tecplot files are processed.                         
- If 'T' then 2D and 3D tecplot files are processed.                         
- If 'A' then all three file types are processed.                            
- If 'p' and preplot is available in the PATH then it will also be run.      
     - If 'r' is also specified, the .dat file will be deleted after preplot.
     - If no 'r' is specified, the .dat file will be gzip'd                  
- If 'g' and not 'p' then the .dat files will be gzip'd.  Ignored if 'p'.    
- If 'b=BASENAME' then only files starting with the path BASENAME are        
     processed.                                                              
     - To process all files in the IO2 directory use 'b=IO2/'   not 'b=IO2'  
     - If 'b=' is not used 'T' and 'S' files are processed in IO2/
\end{verbatim}
The {\tt pTEC} script can be used with up to 6 of the 8 flags in any
combination or order.  However, some of the combinations are not
meaningful (we outline these below).

The capital flags control which type of files will be processed:
({\tt S}) spherical slice, ({\tt T}) 2D and 3D tecplot slices
and ({\tt A}) all types ({\tt S+T}).  If none of these flags is given, then
by default only 2D and 3D tecplot slices ({\tt T}) will be processed.
Using more than one of the flags will have the intuitive result.
By default the files are processed in the {\tt IO2/} directory. This
default behavior can be changed as described below.

For each type of file the individual file from each processor are
concatenated or processed into {\tt .dat} files.  This is an ASCII file
that can be read by tecplot.  Creation of 2D and 3D files just requires
concatenation of the {\tt .tec} files (the associated {\tt .T} header
files are required for determining the number and names of files but
are not included in the concatenation). For spherical files the
program {\tt PostSPH.exe} is run.  This programs must be compiled
before spherical files can be processed.  Go to the main
directory of the distribution and type
\begin{verbatim}
  make PSPH
\end{verbatim}
For spherical plot files the header file ({\tt .S}) 
and the various other files from the different processors 
({\tt .tec}) are read into {\tt PostSPH.exe} 
and written out in the correct format.

Lower case flags control how much processing should take place after
the creation of the {\tt .dat} file.  The '{\tt p}' flag indicates that
the file should be converted to the tecplot native binary format using
the program {\tt preplot} provided in the tecplot distribution.  The
resulting binary files have the extension {\tt .plt} and are machine
independent (see below for a description of preplot).  When '{\tt p}'
is set then the '{\tt r}' flag can be used.  With '{\tt p}' only, the
{\tt .plt} files are created and the original {\tt .dat} files are
gzipped to {\tt.dat.gz} and saved.  If in addition the '{\tt r}' flag
is set then the {\tt .dat} files are removed and only the {\tt .plt}
files remain.

Frequently the code will be run on a remote machine that does not
have {\tt preplot} installed.  In this case the '{\tt g}' flag
can be used.  If this flag is set the {\tt .dat} files are gzipped
to {\tt .dat.gz} so that they are more easily sent over the internet.
This flag is ignored if '{\tt p}' is set.

Finally, the {\tt b=BASENAME} flag can be used to process files in any
directory or to process a subset of the files.  For this flag {\tt
BASENAME} is a string that indicates the path and the initial part of the
filename that should be processed.  The {\tt BASENAME} does not accept
wild cards.  As an example, the command
\begin{verbatim}
  pTEC S b=IO2_save/spN
\end{verbatim}
will process only spherical slice files in the directory {\tt IO2\_save/}
whose filename starts with {\tt spN} (in other words {\tt spN*}).
The command 
\begin{verbatim}
  pTEC S b=IO2_save/
\end{verbatim}
would process all the spherical plot slices in the directory {\tt IO2\_save/}.
Note that the trailing '/' is required so that the string {\tt IO2\_save}
is interpreted as a directory and not the base filename to be used
in the current directory.  Also note that there is only one '{\tt b=}' flag,
but that there are three different file types that are typically located
in two different directories.  If the  '{\tt b=BASENAME}' flag is used, all
file types will be looked for the the directory indicated by {\tt BASENAME}.
For example, the command 
\begin{verbatim}
  pTEC A b=IO2/
\end{verbatim}
will try to process all three file types ({\tt I+S+T}) out of the {\tt
IO2/} directory.  It will find and process the '{\tt S}' and '{\tt T}'
files which would normally be located in this directory, but would not
find and process the '{\tt I}' files unless they had been moved.  We
point out that the command
\begin{verbatim}
  pTEC A 
\end{verbatim}
will process each file type in the default plot directory {\tt IO2/}.

As indicated above Tecplot understands both ASCII files and files in its
native binary format.  Tecplot can read the binary files more quickly
the the ASCII files.  We indicated above that {\tt .dat} ASCII files 
can be converted to Tecplot binaries by running the command
\begin{verbatim}
  preplot newplotarea_plotvar_plotnumber_timestep.dat
\end{verbatim}
This will create the file 
\begin{verbatim}
  newplotarea_plotvar_plotnumber_timestep.plt
\end{verbatim}
without deleting the {\tt .dat} file. These binary files are read more
quickly by Tecplot.  Preplot is a Tecplot program that comes with the
distribution of Tecplot.  Note that preplot only converts a singe file
at a time and does not accept wild cards.  In order to process several
files at once you must write a script that will do this for you.  The
{\tt pTEC} script above can preplot the files for you while processing
all the plot output.  Alternatively, in the {\tt Scripts/TEC/}
directory there are several scripts that process an entire directory
worth of tecplot files with preplot. 
\begin{verbatim}
  ppA
\end{verbatim}
converts all {\tt .dat} files in the current directory to .plt files using
preplot. The {\tt .dat} files remain.
\begin{verbatim}
  ppAr
\end{verbatim}
converts all {\tt .dat} files in the current directory to {\tt .plt} files 
and then deletes the {\tt .dat} files.
\begin{verbatim}
  ppgz KEEP
\end{verbatim}
gunzips all {\tt .dat.gz} files in the current directory.  It then
converts them to {\tt .plt} files using preplot.  If the {\tt KEEP} argument
is present the {\tt .dat} files are again compressed and retained.  It the 
{\tt KEEP} argument is missing the scripts will delete the {\tt .dat} files.

To finish, let us give two additional examples of processing Tecplot
files.  First, assume that \BATSRUS\ has been run on 5 processors and
has written files for a single plot at y=0 at time step 100.  From the
run directory, the command
\begin{verbatim}
  ls IO2/*
\end{verbatim}
would give the following output
\begin{verbatim}
IO2/y=0_mhd_1_n0000100.T
IO2/y=0_mhd_1_n0000100_pe0000.tec
IO2/y=0_mhd_1_n0000100_pe0001.tec
IO2/y=0_mhd_1_n0000100_pe0002.tec
IO2/y=0_mhd_1_n0000100_pe0003.tec
IO2/y=0_mhd_1_n0000100_pe0004.tec
\end{verbatim}
This shows the header file and the individual Tecplot files, one for
each processor.  Typing the command
\begin{verbatim}
  pTEC
\end{verbatim}
will process these data files.  Listing the IO2 directory again would
show the following file:
\begin{verbatim}
  IO2/y=0_mhd_1_n0000100.dat
\end{verbatim}
The file is simply the concatenation of each of the individual files.
To convert to Tecplot binary files we could then type
\begin{verbatim}
  pTEC p
\end{verbatim}
listing the directory will show the original file plus the new binary file.
\begin{verbatim}
y=0_mhd_1_n0000100.dat.gz  
y=0_mhd_1_n0000100.plt
\end{verbatim}
Of course this last step assumes that the current machine has preplot 
installed. The same effect could have been achieved by typing one of 
the following commands
\begin{verbatim}
  pTEC p
  pTEC p T
  pTEC p b=IO2/
  pTEC p T b=IO2/
  pTEC p T b=IO2/y=
\end{verbatim}
As a second example, assume again that \BATSRUS\ has been run on 5
processors.  This time, at step 100, 2 files have been written: x=0 and a
spherical slice.  We are going to assume that the
run was done on a remote machine that does not have tecplot installed.
We wish to process the files as much as possible on the remote machine,
bring them back to a machine that does have tecplot and preplot
installed and then finish the processing locally.  We will also assume
that for some reason the directories in which the files are stored on
the remote machine are not the standard ones.  For this example 
the files that would normally have been in {\tt IO2/} have been moved to 
{\tt IO2\_run1/}. 

To begin we need to compile the post processing codes.  Go to the main
directory of the distribution and type
\begin{verbatim}
  make PSPH
\end{verbatim}
This creates {\tt PostSPH.exe}, which is used
to process the spherical plot files.

Now move to the run directory and view the files.  The command
\begin{verbatim}
  ls IO2_run1/* 
\end{verbatim}
would give the following output
\begin{verbatim}
IO2_run1/spN_mhd_2_n0000100.S           IO2_run1/x=0_mhd_1_n0000100.T
IO2_run1/spN_mhd_2_n0000100_pe0000.tec  IO2_run1/x=0_mhd_1_n0000100_1_pe0000.tec
IO2_run1/spN_mhd_2_n0000100_pe0001.tec  IO2_run1/x=0_mhd_1_n0000100_1_pe0001.tec
IO2_run1/spN_mhd_2_n0000100_pe0002.tec  IO2_run1/x=0_mhd_1_n0000100_1_pe0002.tec
IO2_run1/spN_mhd_2_n0000100_pe0003.tec  IO2_run1/x=0_mhd_1_n0000100_1_pe0003.tec
IO2_run1/spN_mhd_2_n0000100_pe0004.tec  IO2_run1/x=0_mhd_1_n0000100_1_pe0004.tec
IO2_run1/spS_mhd_2_n0000100.S           IO2_run1/x=0_mhd_1_n0000100_2_pe0000.tec
IO2_run1/spS_mhd_2_n0000100_pe0000.tec  IO2_run1/x=0_mhd_1_n0000100_2_pe0001.tec
IO2_run1/spS_mhd_2_n0000100_pe0001.tec  IO2_run1/x=0_mhd_1_n0000100_2_pe0002.tec
IO2_run1/spS_mhd_2_n0000100_pe0002.tec  IO2_run1/x=0_mhd_1_n0000100_2_pe0003.tec
IO2_run1/spS_mhd_2_n0000100_pe0003.tec  IO2_run1/x=0_mhd_1_n0000100_2_pe0004.tec
IO2_run1/spS_mhd_2_n0000100_pe0004.tec  
\end{verbatim}
Note that the northern and southern hemispheres are separated for 
the spherical plot files.  In addition note that for each 'PE' there
are two x=0 files
\begin{verbatim}
  IO2_run1/x=0_mhd_1_n0000100_1_pe0000.tec
  IO2_run1/x=0_mhd_1_n0000100_2_pe0000.tec
\end{verbatim}
The first of these contains the data for this processor and the second
contains the tree information for connecting the blocks together.

Since tecplot and preplot are not installed on this machine we can
only create the {\tt .dat} files here (the '{\tt p}' option will not
do anything).  Because the files have been moved from their standard
directories ({\tt IO2/} we will have to use the '{\tt b=}' flag.  
We can process the files using the command
\begin{verbatim}
  ./pTEC g T S b=IO2_run1/
\end{verbatim}
Note that the three file types cannot be processed with a single command
since they have been moved to new directories.  The output from the 
command would be
\begin{verbatim}
========================================================================
Beginning cat of .tec files                                             
========================================================================
--Working in directory: IO2_run1/   on files: ./*.T ./*.tec
   working on x=0_mhd_1_n0000100 ...
   compressing all *.dat files in directory: IO2_run1
========================================================================
Beginning processing of spherical slice files                           
========================================================================
--Working in directory: IO2_run1/   on files: ./*.S ./*.tec
   working on spN_mhd_2_n0000100 ...
   working on spS_mhd_2_n0000100 ...
   compressing all *.dat files in directory: IO2_run1
\end{verbatim}
We would now bring the files home using ftp or scp.  In this example
we copy all the files into an already existing directory on our
home machine.  From the run directory type
\begin{verbatim}
  scp IO2_run1/*.dat.gz myname@mymachine.edu:testdir/
\end{verbatim}
This would secure copy the {\tt .dat.gz} files to 
a machine named {\tt mymachine.edu} to an account with username {\tt myname}
into the directory {\tt testdir/}.

On my home machine I have placed the following files in the {\tt bin}
directory in my home directory (which is included in my PATH).
\begin{verbatim}
pTEC
ppgz
PostSPH.exe
preplot
\end{verbatim}
Since all these programs can now be found in the path, to finish processing
the files I simply go to the directory {\tt testdir} on my home
machine and do one of two things.  The first option is to type
\begin{verbatim}
  gunzip *
  pTEC A b=
\end{verbatim}
which will gunzip all the files and then process them with {\tt pTEC}.
Since they have already be concatenated, the preplotting step will be
the only on executed.  This command will leave the original files and a
listing of files in the directory will give
\begin{verbatim}
spN_mhd_2_n0000100.dat.gz
spN_mhd_2_n0000100.plt
spS_mhd_2_n0000100.dat.gz
spS_mhd_2_n0000100.plt
x=0_mhd_1_n0000100.dat.gz
x=0_mhd_1_n0000100.plt
\end{verbatim}
Alternately, the simple command
\begin{verbatim}
  ppgz
\end{verbatim}
will gunzip all the files, preplot them and then delete the original files.
A listing of the directory would give.
\begin{verbatim}
in000100N.plt
spN_mhd_2_n0000100.plt
spS_mhd_2_n0000100.plt
x=0_mhd_1_n0000100.plt
\end{verbatim}

%\end{document}


